I like the short form very much, this also gets very close to the python dataclass notation which performs almost the same by specifying class attributes.

The following details raised my attention:

• Do we need developer-overwriteable __init__() methods? I am worried about the possibility to simply specify arbitrary code -- this would undermine the predictability of PICMI objects.
• How are mandatory attributes treated?
• What is the difference between a default argument of the wrong type, and a user-supplied argument of the default type.
• How is this interface used to extend existing PICMI classes in PICMI implementations?

These are design principles, I've sent you an email for a short meeting on the matter to put these design principles into writing.

Thanks for looking at this PR. Here are comments on the issues:

• Regarding __init__, this is where any checks can be done. I don't think there is an issue with adding code to the __init__ routine (at the picmi level). Remember that picmi is monitored and that any changes would need to be approved. For the implementations, the standard would be that the implementation not overwrite the __init__ routine but only add the init method to do what is needed.
• Mandatory arguments are setup the same way but just without a default value, e.g. n_physical_particles : int, .
• I checked this. The default argument does not need to have the specified type (so None is ok). If the user sets the argument to the default value, it is allowed. This is ok, since there is no way to tell the difference.
• The changes here don't require any changes to the implementation (from what it was before).

That sounds great to me.

I would probably still introduce a check member function as we have also the init member function.
That way, we can check physical ranges both in the constructor (or init) as well as before we call the step() or inputs export, respectively. And thus, we can check parameters that users changed in between, e.g., though custom setters, their own properties, or accessing a member variable directly after construction.

This check method can be added, but I would suggest that this should be done in a separate PR.

Once the changes here are accepted, I would suggest that this PR be merged. The other classes can be updated to use the new features in separate PRs (to keep the PRs small). This also allows the work to be spread out (since people are busy).

I've implemented the type checking in all of the classes. All of the defined types are not setup in the picmi_types.py files. Though, there is some kludginess there because of the way the type definitions that are in strings are evaluated. For example, for each type that is used, a module must import the modules used in the type definition (that's why particles.py must import fields for instance).

The problem comes when a type is used that depends on the same module where the type is used. In this case, the module can't import itself, so the type string cannot reference the module. For this reason, I had to define two versions of the GridType, with and without the fields references

An alternative is to do "*" imports, i.e. particles could do "from .fields import *" (so the fields prefix in the type definition is not needed), but this has its own messiness. I'm receptive to other alternative ideas.